perm filename IJCAI.PUB[HAL,HE] blob
sn#153462 filedate 1975-04-10 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00008 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 00002 .TURN ON "∞π↑↓[]{_α#←→&∂"
C00009 00003 .NEXT PAGE
C00012 00004 .NEWSEC AN OVERVIEW OF AL
C00017 00005 .NEWSS PHILOSOPHY OF DESIGN
C00034 00006 .NEWSS GENERAL SYSTEM OUTLINE
C00043 00007 .NEWSEC AN EXAMPLE
C00058 00008 .NEWSEC CONCLUSIONS
C00066 ENDMK
C⊗;
.TURN ON "∞π↑↓[]{_α#←→&∂";
.TURN OFF TAB;
.SPACING 125 MILLS ;
.PREFACE 200 MILLS ;
.INDENT 4,0;
.NOFILL; PREFACE SPREAD; FILL;
.MACRO UNFILL ⊂BEGIN NOFILL;PREFACE 0;TURN OFF "←→";GROUP⊃;
.MACRO REFILL ⊂END; CONTINUE⊃;
.MACRO MAYBREAK ⊂APART;GROUP;⊃;
.MACRO BULL ⊂ONCE; FLUSH LEFT⊃;
.MACRO COMT(X) ⊂BEGIN FILL;PREFACE 125 MILLS;INDENT X,X;}%4{⊃
.COUNT SECTION FROM 1 TO 99 PRINTING ⊂SECTION⊃;
.COUNT SUBSEC FROM 0 TO 99 IN SECTION PRINTING "!.1";
.COUNT SUBSUBSEC FROM 0 TO 99 IN SUBSEC PRINTING "!.1";
.COUNT FOOTNOTE INLINE FROM 1 TO 9 IN PAGE;
.MACRO NEWSEC(TITLE,ID) ⊂
.NEXT SECTION!;
.IF PICLIN≠NULL THEN ALLPIC;
.SECNAME←NULL;
.SSECNAME←NULL;
.SSSNUM←NULL
.NEXT SUBSEC;TABLE←0;
.SECNAME←"TITLE";
.SSECNAME←"ID";
.BEGIN INDENT 0,0;
.SKIP 2;
%5{SECTION!} {SECNAME}%*
.END
.SECNAME←"TITLE";⊃
.MACRO NEWSS(TITLE,ID,LAB) ⊂
.NEXT SUBSEC!;
.IF PICLIN≠NULL THEN ALLPIC;
.SSSNUM←SUBSEC!
.NEXT SUBSUBSEC;
.BEGIN INDENT 0,0;
.IF LINES≤8*SPREAD THEN NEXT PAGE ELSE SKIP 2*SPREAD;
.SSECNAME←"ID";
.IF SSECNAME=NULL THEN SSECNAME←"TITLE";
%5{SUBSEC!} TITLE%*
.END
.⊃
.MACRO NEWSSS(TITLE,LAB) ⊂
.NEXT SUBSUBSEC!;
.IF PICLIN≠NULL THEN ALLPIC;
.SSSNUM←SUBSUBSEC!
.BEGIN INDENT 0,0;
.IF LINES≤6*SPREAD THEN NEXT PAGE ELSE SKIP 1+SPREAD;
%4TITLE%*
.END
.BREAK
.⊃
.MACRO SECREF(LBL)⊂"Section ";SECTION! LBL⊃
.MACRO SSREF(LBL)⊂"Section ";SUBSEC! LBL ⊃
.MACRO SSSREF(LBL)⊂"Section ";SUBSEC! LBL⊃
.AT NULL ⊂IF FILLING THEN
. START BREAK;
. IF LINES<2*SPREAD+1 THEN NEXT PAGE END
. ELSE SKIP SPREAD⊃;
.COMMENT PICTURE MACROS;
.FIGS←TRUE;
.RECURSIVE MACRO STOREPIC(TITLE,LINES,TEMP) ⊂START
.PICLIN←PICLIN&" "[1 TO 2-LENGTH("LINES")]&"LINES";
.PICNUM←PICNUM&" "[1 TO 4-LENGTH(TEMP)]&TEMP;
.PICTLEN←PICTLEN&" "[1 TO 2-LENGTH(LENGTH("TITLE"))]&LENGTH("TITLE");
.PICTIT←PICTIT&"TITLE";
.END⊃
.BOTTOM←50;
.MACRO FULL⊂BOTTOM-3*SPREAD⊃
.MACRO HALF⊂BOTTOM/2-3*SPREAD⊃
.MACRO THIRD⊂BOTTOM/3-3*SPREAD⊃
.MACRO TWOTHIRDS⊂2*BOTTOM/3⊃
.MACRO NEWFIG(TITLE,εLINES,LABEL) ⊂
.FIGURE←FIGURE+1; LABEL TEMP←FIGURE; }Figure {TEMP;
.STOREPIC(|TITLE|,LINES,TEMP) ⊃;
.MACRO FIGREF(LBL)⊂"Figure "; LBL⊃
.MACRO MAKEFIG(TITLE,εLINES,LABEL) ⊂
.FIGURE←FIGURE+1;LABEL TEMP←FIGURE;
.STOREPIC(|TITLE|,LINES,TEMP) ⊃;
.PICLIN←PICNUM←PICTLEN←PICTIT←NULL
.MACRO SMALLPIC⊂⊃
.MACRO ALLPIC⊂⊃
.IF FIGS THEN START
.MACRO PLACEPIC ⊂BEGIN CENTER PREFACE SPREAD-1
.A←PICLIN[1 TO 2]; B←PICNUM[1 TO 4];
.C←PICTLEN[1 TO 2]; D←PICTIT[1 TO C];
.PICLIN←PICLIN[3 TO ∞]; PICNUM←PICNUM[5 TO ∞];
.PICTLEN←PICTLEN[3 TO ∞]; PICTIT←PICTIT[C+1 TO ∞];
.GROUP SKIP A;
Figure {B}
{D}
.SKIP 2*SPREAD;
.END⊃
.RECURSIVE MACRO RSPIC ⊂
.IF LINES-3*SPREAD≥PICLIN[1 TO 2] THEN PLACEPIC
.ELSE START
. TLIN←TLIN&PICLIN[1 TO 2]; PICLIN←PICLIN[3 TO ∞];
. TNUM←TNUM&PICNUM[1 TO 4]; PICNUM←PICNUM[5 TO ∞];
. C←PICTLEN[1 TO 2];
. TTLEN←TTLEN&C; PICTLEN←PICTLEN[3 TO ∞];
. TTIT←TTIT&PICTIT[1 TO C]; PICTIT←PICTIT[C+1 TO ∞];
. END;
.IF PICLIN≠NULL THEN RSPIC⊃
.RECURSIVE MACRO SMALLPIC ⊂
.TLIN←TNUM←TTLEN←TTIT←NULL;
.RSPIC;
.PICLIN←TLIN; PICNUM←TNUM; PICTLEN←TTLEN; PICTIT←TTIT;
.IF LINES<2*SPREAD-1 THEN NEXT PAGE ⊃
.RECURSIVE MACRO ALLPIC ⊂
.IF PICLIN≠NULL THEN SMALLPIC;;
.IF PICLIN≠NULL THEN BEGIN PLACEPIC; ALLPIC END ⊃
.AT NULL ⊂IF FILLING THEN
. START BREAK;
. COMMENT IF LINES<2*SPREAD+1 THEN NEXT PAGE; END
. ELSE SKIP SPREAD⊃;
.BEFORE PAGE ⊂STANDARD TITLES;
. IF PICLIN≠NULL THEN SMALLPIC ⊃
.END COMMENT PICTURE MACROS;
.device xgp
.IF XCRIBL THEN FONT 1 "BASL30[HAL,HE]"
.IF XCRIBL THEN FONT 4 "BASI30[HAL,HE]"
.IF XCRIBL THEN FONT 5 "BASB30"
.IF XCRIBL THEN FONT 6 "BDR40";
.COMMENT IF XCRIBL THEN FONT 7 "LPT";
.!xgplftmar← 200
.PAGE FRAME 28 HIGH 80 WIDE;
.TITLE AREA HEADING LINES 1 TO 2 CHARS 1 TO 80;
.AREA TEXT LINES 3 TO 28 CHARS 1 TO 80;
.TURN ON "%\"
.TABS 17
.SECID←"SECTION";
.SECNAME←NULL
.COUNT PAGE FROM 1 TO 999 PRINTING ⊂PAGE⊃;
.IF XCRIBL THEN SELECT 1
.NEXT PAGE
.SSECNAME←NULL;
.PORTION TITLEPAGE
.BEGIN NOFILL;turn on "↑";SPREAD←1;
.AREA TEXT LINES 1 TO 28 CHARS 1 TO 80
.NEXT PAGE
%1STANFORD ARTIFICIAL INTELLIGENCE LABORATORY →APRIL 1975
.GROUP SKIP 4
.NOFILL CENTER
%6An Overview of AL, A Programming System for Automation
.GROUP SKIP 2
%1Raphael Finkel, Russell Taylor, Robert Bolles, Richard Paul↑*, Jerome Feldman↑*
.GROUP SKIP 2
.FILL ADJUST COMPACT
.NARROW 8,8
AL is an high-level programming system for specification of manipulatory tasks
such as assembly of an object from parts.
AL includes an ALGOL-like source language,
a translator for converting programs into runnable code, and a runtime system
for controlling manipulators and other devices. The system includes
advanced features for describing individual motions of manipulators, for using
sensory information, and for describing assembly algorithms in terms
of common domain-specific primitives. This paper describes the design
of AL, which is currently being implemented as a successor to the Stanford WAVE
system.
.WIDEN
.NOFILL SKIP TO LINE 21
.FILL
∞_→#
.BREAK
%4↑* Jerome Feldman is now at the University of Rochester.
Lou Paul is now at the Stanford Research Institute.
This research was supported in part by the
National Science Foundation under contract No. GIα-42906 and in part by
the Advanced Research
Projects Agency of the Office of Defense under Contract No. DAHC-15-73-C-0435.
The views and conclusions in this document are those of the authors and
should not be interpreted as necessarily representing the official policies,
either expressed or implied, of the
funding agencies.
.END
.ADJUST COMPACT
.SECNAME←NULL
.SSECNAME←NULL
.SSSNUM←NULL
.PORTION BODY;
.COUNT PAGE FROM 1 TO 999 PRINTING ⊂PAGE⊃;
.EVEN HEADING(Page {PAGE!},{SSECNAME},{SSSNUM});
.ODD HEADING({SSSNUM},{SSECNAME},Page {PAGE!});
.NEXT PAGE
.NEWSEC AN OVERVIEW OF AL
This short paper cannot cover the subject of AL with any depth;
a complete discussion may be found in %4AL, A Programming System
for Automation%*, Stanford Artificial Intelligence Laboratory Memo
AIM-243, Stanford University Computer Science Department Report
STAN-CS-74-456, by the authors of this paper.
.NEWSS INTRODUCTION
The development of robot manipulators such as the "Unimate" has led
to the belief that these tools are in some way general-purpose
devices and that they might be programmed like a computer. As a
general-purpose programmable device, the robot manipulator
provides an answer to the need for automation of assembly in batch
manufacturing industries where small production runs rule out
the use of special-purpose equipment.
We are implementing a system called AL for small scale batch manufacturing where
setup time is the key factor. We rely on a symbolic database
and previously-defined assembly primitives to minimize
programming time. The system is capable of top-level planning
and intelligent interpretation of user defined primitives.
The principal aim of this work is not to provide a factory floor
programming system but rather
to design a language which will be
a tool for
investigating the difficulty, necessary programming time, and
feasibility of writing programs to control assembly operations.
.NEWSS PHILOSOPHY OF DESIGN
.NEWSSS DATA AND CONTROL STRUCTURES
The principal mode of input to AL is
textual, as opposed to spoken or manual (joystick). There are levels
of complexity which are much more readily transmitted from man to
machine through an interface of symbolic text.
Simultaneous motions of two arms and termination
and error conditions are more likely to be unambiguously described
through the medium of text; the structure
imposed on the textual language forces a consistent framework on
initially less structured intuitive ideas. Non-textual forms of
input for defining target locations and
suggesting arm trajectories to avoid collisions
are most useful when applied in conjunction with a program text which
supplies the skeletal intent of the programmer.
The supervisor level of AL is simple enough to allow
natural teaching by showing; it should be easy to interface such
devices as joysticks and vocal input into AL, although we
do not intend to do so at present.
Experience with languages like SAIL and WAVE has shown that text macros are a
useful feature; they reduce the amount of repetitive
typing. AL has a general-purpose text macro system
interfaced into the scanner and parser.
The datatypes available include those types necessary to refer to
one-dimensional measures (like distance, time, mass) and
three-dimensional measures (like directed distance, locations,
orientations). Arithmetic operators are available not only for
the standard scalar operations like multiplication and addition, but
also for such operations as rotation and translation.
Provision is made for
simultaneous execution of several processes This allows
calculation
and arm motion to take place simultaneously; several
manipulators can be in independent or coordinated motion.
.NEWSSS MOTION SPECIFICATIONS
Experience with WAVE has shown that calculating trajectories for
manipulators is desirable but time-consuming.
Trajectory calculations, together with all other calculations which
need only be performed once, are done at compile time. This
allocation of effort drastically reduces the computing load at
execution time and eliminates wasteful recomputation every time a
sequence of actions is executed. This leads to a clear distinction
between compile-time and runtime.
Trajectories may be specified to pass through
given intermediate points. The primary use of this is to avoid
collisions during the motion. It is also useful in specifying
complicated motions.
A wide range of exceptional conditions can occur during the motion of a
manipulator.
Appropriate action must be taken as soon as any
of these occurs, for example to start up a new concurrent process
or to notify the user.
Therefore, AL allows the
flexible specification of conditions to monitor during the
course of motions (and during execution of blocks of code in
general), and what to do in the case that a tested condition occurs.
.NEWSSS USE OF A PLANNING MODEL
Since locations are not known exactly during the planning of a
trajectory, there is a clear distinction between planned
values and runtime values. Planned values are used for
trajectory calculation; at runtime, trajectories are modified if
necessary to account for any discrepancies. The planned values are
therefore a database on which trajectory calculations are computed.
This database forms a %4world model%*.
Assembly tasks require that one object be affixed to another. We
model this by having a semantic attachment between objects.
If two objects are affixed, and
one moves, the second one should move accordingly, that
is, its planning value should be properly modified. The world
model includes information on attachments of objects.
The affixment
concept carries over to the runtime system, which does the equivalent
modifications of the actual values. This saves the user untold
bookkeeping operations to determine where an object is after its base
has been moved.
More generally,
the compiler maintains a wide variety of information
about expected runtime states. This includes
information like the accuracy within which the planning
value is known, how heavy an object is, how many faces it has on
which it can rest, how wide the fingers of an arm should open to
grasp it. This information may come from several sources, including
explicit assertions by the user
and built-in knowledge about the system hardware.
AL has a general framework for representing
and using such knowledge.
.NEWSSS USE OF DOMAIN-SPECIFIC KNOWLEDGE
The system has enough domain-specific knowledge to allow
programs to be written in terms of common assembly operations, rather
than exclusively in terms of detailed single motions. At the
simplest level, this involves a library of common
assembly "macro-operations" that can be conditionally expanded to
perform particular subtasks. Beyond this, we foresee an
interactive system that can take a "high level" description of an
assembly algorithm and fill in many of the detailed decisions
required to produce a consistent and efficient output program.
A user can specify different parts of a task at various
levels of detail. The system accepts explicit advice
telling exactly how some particular subtask is to be accomplished and
then completes the program in a way that does not conflict with that advice.
This is especially
important for early versions of AL, which are not likely to be very
"smart" and will therefore require a fair amount of explicit help.
The user can make assertions describing the "intent" of a particular
piece of code by specifying any (non-obvious)
prerequisites or updates to the world model.
Such information can be used by the AL strategist to generate
code to cause the desired result.
This facility is
especially important for programs that mix both high and low-level
primitives. Similarly, the system can show the user how
it is filling in the details to produce an output program, and why.
This is very important both for debugging and for explaining to the
user any requests for advice that it must make.
.NEWSSS THE RUNTIME SYSTEM
The calculation of trajectories is time-consuming but not
time-critical; servoing of devices is time-critical but not
especially time-consuming.
The compiler is written in a high-level language, SAIL, and
the runtime programs are written in assembly language.
As one
execution computer will be required for each work station in a
factory, and as the runtime code and its memory requirements will be
quite small, the runtime system is designed for a minicomputer.
The runtime system supports simultaneous executions of many
processes. Several manipulators
or devices
might be running simultaneously, and each
motor requires a separate process; several condition
monitors might be active; several code segments (doing, perhaps,
calculations) might be simultaneously active. Those processes which
are dealing with real-time devices (joint servos and condition
checkers) must be guaranteed service at regular intervals; the
computation processes can fill in any time gaps.
Trajectories are calculated by the compiler on the basis of
incomplete information. At runtime, it is necessary to modify those
plans to fit them to the somewhat different actual location of
objects. Certain information must be carried at
runtime to accomplish this modification.
The wide range of conceivable tasks implies that pure hardware
servoing does not in general suffice. The reason for this is that
hardware servoing restricts use to one of a small number of servo
modes (typically position, velocity, or force), and has no provision
for motions of accommodation or motions whose modes might change in
midstream due to some software-detectable condition. Pure hardware
servoing could not be readily modified to account for new feedback
devices or methods. A philosophy of %4software servoing%* has these
advantages: It is possible to program the manner in which feedback is
to be used, to interface new types of sensors,
to modify the servo while the arm is in motion,
to supply the driving program with information concerning
the success of the motion as well as to keep it up-to-date on the arm
status.
It also allows coordination of several arms, with one acting as
a master and the others following.
Hardware servoing would not save
computation since the
computer would need to perform an
equivalent
servo calculation in order to understand
what the manipulator is doing to interact with the task.
.NEWSS GENERAL SYSTEM OUTLINE
.NEWSSS HARDWARE
Currently two Stanford Electric Arms, built by Victor
Scheinman [Scheinman], are available. They are called YELLOW and BLUE. Each has
six joints and a hand that can open and close. The joints are
controlled by electric motors; each joint has both position
and velocity feedback.
Motor drives are sent from the computer to
the arm via a digital-to-analog converter (D-to-A); feedback signals are
routed through an analog-to-digital converter (A-to-D) back to the computer.
Various other devices are designed and implemented as needed.
We use tools, jigs and special markings for several purposes:
to render a task possible (an example is the arm itself), to improve
efficiency (a mechanical screwdriver), and to overcome some of our
sensory and mechanical limitations (a screw dispenser).
AL resides on two computers: The PDP-10 for all planning,
and a PDP-11/45 for the execution of the plans. The former is run as a
timesharing computer (under a modified DEC system); the latter is
operated in stand-alone mode under the AL runtime system.
Each
computer is capable of generating an interrupt in the other, and the
PDP-10 has complete control over the PDP-11 console and unibus.
It is not certain exactly what the minimum runtime computer configuration
will be; we use floating point and memory management, but it is not
clear that this is altogether necessary.
.NEWSSS SOFTWARE
See {NEWFIG Overall system, TWOTHIRDS, sis←} for a picture of the
system.
The SUPERVISOR is the top level of AL. It runs on
the timesharing computer
and provides an interface between the user and the other
parts of the system: 1) listening to the user's console and
interpreting simple command language input; 2) controlling the
compiler, starting it and relaying its error messages back to the
user; 3) signalling the loader when it is necessary to place compiled
code into the mini; 4) handling the runtime interface to the mini.
The USER sits at a console and makes requests of AL. These
fall into several categories: compilation, loading, execution of
programs, debugging of code, requesting of status information, asking
for immediate arm motion, saving and restoring the state of the world
at safe points, requesting explanation of certain compiler decisions.
There are two different consoles at which a user can sit:
one is connected to the timesharing computer,
through which she can speak to the supervisor
and all the parts of AL residing on the timesharing
computer; the other is connected
to the mini, and through it the user can investigate the runtime
system and cause modifications.
The COMPILER reads AL programs from files (or, optionally,
directly from the user's console) and produces load modules. The
compiler is divided into three phases: The PARSER,
which produces parse trees of the program,
the EXPANDER,
which expands those parse trees by replacing high-level primitives
with low-level primitives, and
the TRAJECTORY CALCULATOR and CODE GENERATOR, which creates the
output files.
The LOADER takes the load modules prepared by the compiler
and enters them into the mini's runtime system. Address relocation
and linking are done at this time. The loader also sets up the data
area in the runtime interface in the timesharing
computer; these data include
output strings, procedure linkages, and information necessary for
diagnostic purposes during runtime. Loading is often done in a
partially incremental fashion, installing new code following
previously loaded code.
The RUNTIME INTERFACE, which resides in the
timesharing computer, is charged with initiating the mini
program, fielding procedure calls from the running program to
procedures on the timesharing machine,
returning values from these procedures, and
fetching values from the mini for debugging purposes. The
interface has the power to interrupt the execution of the program and
to modify the status of the runtime system, for example, by patching
in additional programs or modifying the values of some variables.
This allows the user to control the program through the timesharing
computer.
The RUNTIME SYSTEM is the set of programs which reside in the
mini. This system includes kernel programs for time-slice cpu
sharing and process control and a set of dynamically created
processes. These are of three basic types: a) An INTERPRETER
examines the code prepared by the compiler and executes the numeric
computations requested. When a move is to be started, the
interpreter creates a servo for each joint and waits until all these
servos are finished. b) A SERVO handles the motion of one moving joint.
c) A CONDITION-MONITOR repeatedly examines certain conditions
(whatever the programmer has specified). If it should discover that
its condition has occurred, it creates an interpreter to take
appropriate action.
The runtime system also includes routines for communication with the
runtime interface in the timesharing computer.
.NEWSEC AN EXAMPLE
A simple task dealing with the objects shown in
{NEWFIG Layout for Example,TWOTHIRDS,lay←}
illustrates some
of the features of AL:
.BEGIN SPREAD←0;PREFACE 0;INDENT 10,10
1. Pick up the bracket with the YELLOW arm and position it next to
the beam so that the holes line up,
2. Pick up the bolt with the BLUE arm,
3. Fasten the bracket to the beam by inserting the bolt in the holes,
4. Return the arms to their park positions.
.END
Some of the features to be demonstrated are: the affix structure,
reference frames, dimensions, and multi-processing. We demonstrate
these capabilities by presenting a highly commented AL program to
accomplish the task stated above.
AL is a multi-level programming language; at one extreme the user
can write detailed, system-like programs and at the other she can
describe the tasks and any partial ordering among them and let the
system determine necessary details. Our example is written in an
intermediate level. In particular, it assumes that there are several
general-purpose macros and routines which understand how to GRASP and
RELEASE things and carry out a NORMAL_SEARCH to insert something into
a hole.
Capitalized words in the example are key words within AL. Lower case
words are user-defined identifiers. Comments are surrounded by curly brackets.
.BEGIN "EXAMPLE";NOFILL;INDENT 0,0;PREFACE 0;
whole_task: BEGIN
.COMT 4
α{First declare the necessary FRAMEs and describe how they are
initially related. The attach structure representing the initial
world is shown in
{NEWFIG Attach Structures for the Task Example,FULL,ats←}.
The arrows indicate how the movement of a
frame affects other frames. If a frame at the tail of an arrow
is moved (by the arm, visually updated, etc.) the frame at the
head of the arrow will be automatically updated. The double
arrows are the results of RIGIDLY AFFIXing one frame to
another.α}
.END
FRAME beam, beam_hole; FRAME bolt;
FRAME bracket, bracket_hole, bracket_grasp;
beam α← FRAME(ROT(Z, 90*DEG), VECTOR(10,6,0));
.COMT 4
α{The beam is expected to be positioned at (10,6,0) in the station's
coordinate system (all measurements are in centimeters) and rotated 90
degrees about the station's Z vector. AL knows about dimensions like DEG
for degrees. Dimensions are adjuncts to variable types; new ones can
be defined in terms of old ones.α}
.END
beam_hole α← beam*TRANS(ROT(X, 90*DEG), VECTOR(3,0,7));
.COMT 4
α{The TRANS represents the position of the beam_hole with respect to the
beam. The premultiplication by the frame beam positions the beam_hole in
the station's coordinate system.α}
.END
AFFIX beam_hole TO beam; %4α{As shown in {FIGREF ats}α}%*
ASSERT FORM(DEPROACH, beam_hole, TRANS(NILROT,VECTOR(0,0,-3));
.COMT 4
α{Trajectories consist of a path from the current position, through a
departure point, possibly through some via points, through an approach
point, and finally to the destination. All FRAMEs have a DEPROACH TRANS
associated with them. TRANSes are essentially the same as FRAMEs.
Whenever leaving (or moving to) a FRAME the standard departure (or
approach) used is that FRAME's DEPROACH TRANS. The station has a DEPROACH
TRANS which is three inches above it. Whenever one FRAME is AFFIXed to
another, by default the former takes on the later's DEPROACH. The result
of this ASSERT
is that the arms will approach the beam hole from the side instead of from
above.
.END
bracket α← FRAME(ROT(Z,45*DEG),VECTOR(20,14,0));
bracket_hole α← bracket*TRANS(ROT(X,180*DEG),VECTOR(3,3,0));
AFFIX bracket_hole TO bracket;
bracket_grasp α← bracket*TRANS(ROT(X,180*DEG),VECTOR(0,3,3));
AFFIX bracket_grasp TO bracket RIGIDLY;
.COMT 4
α{The RIGID AFFIXment insures that a change of bracket_grasp will
automatically change bracket, which in turn will automatically change
bracket_hole. This is quite convenient if the position of the whole
`object' is being updated by one grasping position (ie. bracket_grasp).α}
.END
bolt α← FRAME(ROT(Z,90*DEG)*ROT(X,180*DEG),VECTOR(16,30,0));
.COMT 4
α{The rotation portion of the FRAME has been specified as a composition of
two primitive rotations.α}
.END
DEFINE OZ = "72.007789*DYNES";
.COMT 4
α{Some of the standard macros are defined next.α}
.END
DEFINE grasp(TRANS special_departure,special_approach;
FRAME ATOM the_arm (DEFAULT YELLOW);
FRAME object,grasp_point,thing_object_affixed_to;
DISTANCE SCALAR opening_before_departure,
opening_for_approach(DEFAULT 15*CM),
thickness(DEFAULT .3*CM)) = " ... ";
.COMT 4
α{The expansion of such a macro can depend upon the supplied arguments, the
DEFAULT arguments, and any values in the current planning model.α}
.END
DEFINE release(FRAME ATOM the_arm(DEFAULT YELLOW);
FRAME the_object,the_new_parent;
DISTANCE SCALAR the_opening(DEFAULT 15*CM)) = " ... ";
DEFINE normal_search(FRAME ATOM the_arm(DEFAULT YELLOW);
DISTANCE SCALAR increment(DEFAULT .3*CM), distance_fwd;
FORCE SCALAR stopping_force;
SCALAR number_of_tries(DEFAULT 9)) = " ... ";
.COMT 4
α{This includes some automatic error recovery and a call to the operator if
something drastic goes wrong.α}
.END
COBEGIN
.COMT 4
α{This COBEGIN-COEND construction describes two independent
subtasks (one for YELLOW and one for BLUE) which can be executed in any
order determined by the runtime system; in parallel or serially. This, of
course, assumes that the two arms work in completely separate parts of the
workstation so there is no possibility of a collision.α}
.END
ypickup: BEGIN %4α{pick up the bracket with yellowα}%*
grasp(object=bracket,grasp_point=bracket_grasp,opening_for_approach=3*CM);
.COMT 8
α{Only the necessary parameters need to be specified. By default the
YELLOW arm will be used and there will be no special approaches or
departures. One effect of grasp is to AFFIX the object to the arm.α}
.END
MOVE bracket_hole TO beam_hole + VECTOR(0,0,-.3) WRT beam_hole;
.COMT 8
α{The YELLOW arm (since it holds the bracket to which bracket_hole is
AFFIXed) positions itself so that the bracket_hole lines up with the
beam_hole, but is .3 cm away from the beam_hole. The WRT operator is
one way of describing a vector within a frame of reference other than
the station's.α}
.END
MOVE YELLOW TO ⊗ + VECTOR(0,0,.6) WRT beam_hole
ON FORCE(Z WRT beam_hole)>50*OZ DO STOP YELLOW
ON ARRIVAL DO ABORT("*** error *** bracket went too far");
.COMT 8
α{The ⊗ represents the current position of the arm. The arm moves .6 cm
in Z relative to the beam_hole's frame. The purpose of this move is
to push the bracket up against the beam. If the beam is there, the
arm will sense an opposing force. If not, the arm will succeed in
moving forward the prescribed .6 cm. In order to check for these
possibilities, two condition monitors have been included with the MOVE
statement. The first one monitors the force and stops the arm if the
force exceeds 50 ounces (which means everything is ok). The second
one is an interrupt type condition. If the arm successfully carries
out the complete MOVE, this monitor is awakened, the message is
printed, and control is given to an operator.α}
.END
END ypickup;
bpickup: BEGIN %4α{pick up the bolt with blueα}%*
grasp(the_arm=BLUE,the_object=bolt,grasp_point=bolt,
opening_for_approach=3*CM);
END bpickup;
COEND;
.COMT 4
α{{FIGREF ats} shows the world after the parts have been picked up.α}
.END
MOVE bolt TO beam_hole + VECTOR(0,0,-5.3) WRT beam_hole;
.COMT 4
α{The BLUE arm positions itself so that the bolt is lined up with the
beam_hole and its tip is .3 cm away from the outside of the bracket_hole.α}
.END
normal_search(BLUE, .2*CM, 1.6*CM, 60*OZ, 9);
.COMT 4
α{This pushes the bolt thru the bracket_hole and partly into the beam_hole.
If control continues past this statement the bolt is assumed to be partly
in the hole.α}
.END
MOVE BLUE TO ⊗ * FRAME(ROT(Z,90*DEG),VECTOR(0,0,4))
ON FORCE(Z WRT BLUE) > 60*OZ DO STOP BLUE;
.COMT 4
α{This pushes and twists the bolt into the hole. When the force exceeds 60
ounces, the bolt is assumed to be completely seated in the hole. There is
no check to make sure the bolt seats properly.α}
.END
COBEGIN
parky: BEGIN %4α{release the bracket and parkα}%*
release(the_object=bracket,the_opening=3*CM,the_new_parent=beam);
MOVE YELLOW TO YPARK;
END parky;
parkb: BEGIN %4α{release the bolt and parkα}%*
release(the_arm=BLUE,the_object=bolt,the_opening=3*CM,the_new_parent=beam);
MOVE BLUE TO BPARK;
END parkb;
COEND;
END whole_task
.END "EXAMPLE"
.NEWSEC CONCLUSIONS
AL is important for several reasons. It shows what sort of
considerations are necessary for flexible control of mechanical
manipulation. It demonstrates the feasibility of programmable
assembly. It provides a research tool for investigation of new modes
of software servoing, assembly primitives, arm-control primitives,
and interactive real-time real-world systems.
AL is currently limited by the lack of certain features which would
make it more competent. Many of these have to do with the fact that
feedback is used only in a threshold way; either a monitor triggers
or it does not. Fine control of the arm would be enhanced by more
sensitive force-sensing elements on the hand and a means of
programming accommodating, non-threshold response to this sensory
input. Visual feedback should be implemented to provide better
positioning capability, error detection, and error recovery. Moving
assembly lines imply that AL should be able to handle motions which
it does not cause directly through manipulation; objects should have
a dynamic capablility. Collision detection and avoidance remain
difficult issues. AL would be more error-free if the trajectory
calculator could ensure that the arms never interfere with each other
or with objects in the current world.